[[Category:Fritzbot ET]]
== FRITZBOT ET BUG LIST ==

Here is a place where we can compile all the known bugs, and track their status. Please leave as much detailed info as possible as to what the bug is, where it occurred, and the best way to replicate it (if possible).


== KNOWN BUGS: ==

8. Hobbit's ET Waypointing Tool's aiscript default savename is set by the name of the aiscript that was loaded but NOT by the name used last in saving.  Consequently I have destroyed the last changes in an aiscript multiple times when switching projects.  Example starting a new aiscript, NEW, edit, SAVE (and set filename)<enter>, more edits, SAVE <enter> replaces the old project not the new project aiscript!  The default filename should be set by that last saved OR loaded.  And the editor should do the normal (1) rename old aiscript to bak (replacing old one), (2) save new aiscript.

9. Hobbit's ET Waypointing Tool's aiscript verification reports an error in activateAction_Group if the group number is larger than the last Action ID in the nav file.  This suggests that it is checking the parameter against the action ID numbers rather than the group numbers defined in the nav.  Likely got copied from verification of the activateAction command.

== FIXED BUGS: ==

1. Bots aren't recognizing / using sliding doors. Maybe this is a feature request. A couple maps that are being waypointed have examples. I'll send navs if you need to take a look.

2. Medics still freeze up sometimes.

3. Engs sometimes go to plant, drop dyno, then forget they dropped it and camp waiting to recharge.

4. Bots sometimes lock up or freeze around landmines. EDIT: This affects all bots in the game (not just near the mines). 

5. Sometimes bots freeze up while trying to get items. EDIT: Example of this is if docs are dropped, sometimes they can't calculate a path to them. Seems to be related to distance (Rocket and Rommel are good maps to test).

6. Mobile MG42 soldiers that prone when in a firefight (before getting to a specific mobilemg42 camp) seem to be staying in place even after the firefight is over.

7. I have observed in campaign testing medics with max light weapons pointing their akimbo pistols at a nearly dead comrade bot and then doing nothing.  The 2 bots can stand around for a long time if the enemy never comes their way.  (TomTom 11/24/2006 FritzBot ET 0.70b multiple maps) (This was also previously noted in 0.70 see forum.)

== REQUESTED: KNOWN ET BUGS THAT SHOULD BE FIXED IN FRITZBOT ET==

1. Too many entities crash ET.  Fix prevents new entities being spawned (e.g. airstrikes) if MAX entities would be exceeded.

2. Script file globalaccums 8 and 9 exceed array index and corrupt other memory.

3. Script file commands cvar set, bitset and bitreset do nothing.  Command cvar inc (increment) ignores parameter so no decrement possible.

== REQUESTED: NEW FUNCTIONALITY ==

1. Finish vehicle support.  Bots should not attack invulnerable vehicles like the truck in supplydepot and the train in railgun.

2. Finish vehicle support.  Enemy bots should be able to man the mounted mg (like they do in Bobots)

3. Finish vehicle support. Bots from both teams should be able to use the same vehicle (e.g train in railgun).

4. Extend vehicle support.  Bots should be able to use non-objective vehicles (script movers) like trams, subways, gliders etc.   Currently problems arise when pathing these since the bots have to be trapped inside for the duration of travel.  Consequently the bots may time out, try to exit, kill themselves, get crushed or expose themselves to enemy fire.

5. Health and Ammo roams.  There should be a way to flag a roam so that a bot out of ammo or below 10-30% health would treat the roam at health and ammo cabinets as equal in importance as the top priority actions.  Could be done as a new or existing action roam type, say use the ent number for the action as flags (1 health, 2 ammo, 3 both).  The distance to the roam could also be used as part of the bot's decision making.

6. Convert AI selection of objectives from a flat to a cellular model.  Currently a bot trapped inside an enemy position will not pursue inside objectives since these have to be disabled so that teams bots on the outside don't chose these objectives then zombie because of an path obstruction(s) (e.g. constructed barrier, destroyed ramp...).  However if the bot selection of next objective determined navigation based on a cellular model, then a trapped bot would pursue the inside objective since he was in the same or a connected cell, while a team bot on the outside would filter out that objective because his cell was not connected at the time.  This would require a cell manager with a data structure that would track on a team basis what other cells a given cell is connected to;
 //example of data structure as Array of arrays
 enum eCellteam = {none=-1, both, axis, allies); 
 eCellteam sCell_connect[8];
 sCell_connect cell_nets[8];
It would also require a new aiscript command '''cell_connect <cell1> <cell2> <2way> <team>''' that would be used along side associated node_connects in action tests and the default script block.  The effect of the command would be to invoke the cell manager maintenance function to update the cell-nets.  
There would also have to be a second cell-manager function that would take the list of active actions and create a filtered list for the bot requesting its next objective.  Since bots chose objectives not more often than once a few seconds this extra computing should be easily hidden from affecting gameplay.  To speed up processing...

There would have to be two new console commands namely '''node_cell <ID> <cell_num>''' so waypointers could set the cell number for a node and '''node_defaultcell <cell_num>''' to make adding nodes easier.  The node hud and  node_info commands would need to be updated to show the cell number.  For compatibility the nav file need not be changed as the 2-3 bits needed to define the cell_number could be considered as just the uppermost bits of the node group number.  The node group number then would have those bits masked off accordingly.  Older flat maps would still work since all their nodes and consequently their actions would be in cell zero (the world cell).  For simplicity Actions would inherit the cell of their close node.
In usage when a cell loses focus you would still disable the low priority objectives (camps and roams) since bots that that cannot advance the game objective state should return to the area of fighting.  But CVops and engrs on the other hand could remain inside to pursue available dynamite/satchel objectives (and along with other bots steal and spawnflag objectives).

[http://wiki.bots-united.com/index.php/FritzBuglist_ET Permanent link to this page]
[[Category:FritzBot ET]]

[[Category:FritzBot ET]]
